寫在前面
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。今天談的 KPI、KRI 與 Management Review（管理審查），也不是 CRA 規定企業一定要建立的管理架構，而是我在思考：「CRA 從專案轉成日常運作之後，要怎麼知道這套機制還有效？」時，逐漸整理出來的一些管理想法。

Day 22 談 Ready，接下來我開始想：一年後呢？
Day 22 我談到 CRA Readiness（CRA 準備度），也提到我現在不太喜歡只問「CRA 完成幾 %？」我反而比較在意的是：「如果明天真的發生事情，這套機制跑不跑得起來？」
但再往後想一步，就會出現另一個問題。假設到了 2027 年 12 月，Product Classification（產品分類）完成了、SSDLC（Secure Software Development Life Cycle，安全軟體開發生命週期）建立了、SBOM（Software Bill of Materials，軟體物料清單）可以產出、PSIRT（Product Security Incident Response Team，產品資安事件應變團隊）也開始運作，Technical Documentation（技術文件）與 Conformity Assessment（符合性評估）也都準備好了，是不是就可以宣布「CRA Project Closed」，然後大家回到原來的工作？
我自己越做到後面，反而越覺得不是。因為 Product 還在市場上，Software 還會更新，Supplier 可能改變，Third-party Component（第三方元件）會 EOL（End of Life，生命週期終止），新的 Vulnerability（漏洞）也會持續被發現。所以 CRA 真正進入日常運作之後，我覺得管理問題會從「當初有沒有完成？」慢慢變成「現在還有沒有持續有效運作？」這也是我開始思考 KPI、KRI 與 Management Review 的原因。

一、最直覺的方式，KPI
企業做管理，最自然想到的通常就是 KPI（Key Performance Indicator，關鍵績效指標）。例如 CRA 可以看 CRA Product Classification Coverage（CRA 產品分類涵蓋率）、Product Risk Assessment Coverage（產品風險評估涵蓋率）、Valid SBOM Coverage（有效 SBOM 涵蓋率）、Vulnerability Remediation within SLA（漏洞於 SLA 內完成改善比例）、Supplier Security Assessment Coverage（供應商資安評估涵蓋率），以及 Technical Documentation Readiness（技術文件準備度）等。
這些指標都很合理，也確實可以幫助我們知道 Process（流程）到底有沒有被執行。但我自己很快就想到另一個問題：如果這些 KPI 全部都是 100%，是不是就代表 Product Cybersecurity 很好？
我自己不太敢這樣說。因為 KPI 通常比較擅長回答「我們該做的事情，有沒有做？」但它不一定能告訴我們「Product Cybersecurity Risk（產品資安風險）是不是正在累積？」所以我開始把 KPI 跟另一個概念分開來看，也就是 KRI（Key Risk Indicator，關鍵風險指標）。

二、我自己怎麼區分 KPI 與 KRI？
這不是 CRA 的正式分類，而是我自己在做 Governance（治理）時比較方便理解的方式。
KPI 我比較會拿來看 Process Performance（流程績效），例如 98% Product 已完成 CRA Classification、95% Product 已具備有效 SBOM、90% High Vulnerability 在公司設定的 SLA 內完成改善。它比較像是在回答：「我們事情做得怎麼樣？」
KRI 則比較像是看 Risk Exposure（風險曝險），例如還有多少 Critical Vulnerability（重大漏洞）逾期未處理、有多少 Product 使用已經停止 Security Support（安全支援）的關鍵元件，或有多少 Product 已經發生重大改版，但 Cybersecurity Risk Assessment 還沒有重新檢視。它提醒我的問題比較像是：「有沒有某些 Risk 正在慢慢累積？」
這兩種資訊，我覺得最好不要混在一起。

三、第一個我會關注的 KPI：Product Scope Coverage
CRA 很多事情都是從 Product Scope（產品範圍）開始，所以我可能會先建立 CRA Product Classification Coverage，也就是「已完成 CRA Applicability / Classification 的 Product ÷ 應評估的 Product × 100%」。
如果這個數字是 100%，至少代表公司已經知道哪些 Product 要進一步處理。但這個 KPI 有一個很明顯的陷阱：如果 Product Inventory（產品清冊）本身就不完整呢？
假設清冊裡只有 100 個 Product，而且 100 個都完成分類，看起來是 100%；但實際上公司有 120 個 Product，那這個 100% 其實沒有想像中那麼有意義。
所以除了 Classification Coverage，我可能還會搭配 New Product Screening（新產品篩選）機制，例如確認新 Product 在 Release 前是否完成 CRA Applicability Assessment（CRA 適用性評估）。這樣才比較能避免舊產品全部 Green，新產品卻從流程旁邊繞過去。

四、Risk Assessment 也不能只看「完成率」
第二個很自然的 KPI 是 Product Cybersecurity Risk Assessment Coverage，也就是 In-scope Product（適用範圍內產品）有多少比例完成 Cybersecurity Risk Assessment。
但我自己還會再問：「這份 Risk Assessment 是什麼時候做的？」
如果三年前做過一次，之後 Product 已經改了五個版本、新增 Network Interface、換過 Third-party Component，Risk Assessment 卻還是原來那一份，那「Completed」可能沒有太大的管理意義。所以除了 Completion Rate，我可能還會看 Overdue Risk Assessment Review（逾期未重新檢視的風險評估），以及 Product Change 後是否完成 Cybersecurity Impact Review（資安影響檢視）。
這其實也跟 Day 17 談的 Substantial Modification（實質修改）接起來了。CRA 的 Product Risk 並不是評估一次之後就永遠不變。

五、SBOM 也一樣，「有」跟「有效」是兩件事
SBOM 很適合拿來做 Dashboard，最簡單的指標就是 SBOM Coverage。但如果是我，我可能會多加一個字，變成 Valid SBOM Coverage。
因為「有一份 SBOM」跟「有一份可以正確對應目前 Product Release Version（產品發布版本）的 SBOM」，其實是兩件不同的事情。所以除了 Coverage，我可能還會關注 SBOM Update Timeliness（SBOM 更新及時性）、SBOM / Product Version Consistency（SBOM 與產品版本一致性），甚至 Vulnerability Monitoring Coverage（漏洞監控涵蓋率）。
如果 SBOM 每次 Release 都有產出，但產出之後只是丟進 Folder，從來沒有拿來做 Component Vulnerability Monitoring（元件漏洞監控），那我自己會覺得：SBOM Artifact 有了，但 SBOM Capability 還沒有完全建立。

六、Vulnerability KPI 最容易漂亮，也最容易誤導
Product Security 很自然會看 Critical / High Vulnerability Remediation within SLA，或者 MTTR（Mean Time to Remediate，平均修復時間）。這些都很合理，但這一類 KPI，我自己會特別小心。
假設今年有 100 個 High Vulnerability，全部都在 30 天內 Close，Dashboard 顯示 100% Green。結果仔細看才發現，真正完成 Fix 的只有 20 個，另外 80 個全部是 Risk Accepted（風險接受）。那「100% Closed」跟「100% Remediated」顯然不是同一件事情。
所以我自己在設計這類指標時，會想把 **Remediated（已改善）**跟 **Closed（已結案）**分開。因為如果 KPI 定義不清楚，數字可能非常漂亮，但它描述的其實不是我們真正想看的事情。

七、這就是為什麼我還會搭配 KRI
假設 KPI 告訴我 Critical Vulnerability SLA Compliance = 95%，看起來不錯。但我還會想知道 Open Critical Vulnerability 有多少、Overdue Critical Vulnerability 有多少、Risk Accepted Critical Vulnerability 有多少，有沒有 Repeated Vulnerability（重複發生的漏洞），以及有沒有 Known Exploited Vulnerability Exposure（已知遭利用漏洞曝險）。
這些數字不一定表示 Process 做得不好，但它們可能提醒 Management：**Product Risk Exposure 正在增加。**對我而言，這就是 KRI 的價值。

八、Article 14 我會另外看「判斷能力」，而不只是通報件數
CRA Article 14 的 Reporting Obligations（通報義務）自 2026 年 9 月 11 日開始適用，所以這一塊，我可能會建立 24h Early Warning Timeliness、72h Notification Timeliness、Final Report Completion、Reporting Decision Documentation Rate 之類的指標。
但這裡有一個很有意思的問題：Article 14 Reportable Case = 0，到底是不是好事？
可能真的沒有符合通報條件的 Case，但也可能是 Vulnerability 沒有被發現，或者 Case 有進來，卻沒有人進行 Article 14 Applicability Assessment（Article 14 適用性評估）。所以「0 件通報」本身，我不會直接把它當成 Good KPI。
我反而可能更想知道，應該被評估的 Vulnerability Case，有多少真的完成 Article 14 Assessment？相關 Decision Record（判斷紀錄）有沒有留下？這樣比較能看出真正的 Capability，也比較不會產生「為了 KPI 好看，最好不要有通報」這種奇怪的 Incentive（誘因）。

九、Supplier Risk，我也會開始從 Product 角度看
CRA 做到後面，我越來越覺得 Supplier Security（供應商資安）不能只看成 Procurement Risk（採購風險）。例如我可能關心 Critical Supplier without Security Requirement、Unsupported Third-party Component、Supplier Security Update SLA Gap，以及 Supplier Vulnerability Notification Failure。
因為 Third-party Component 一旦整合進 Product，它帶來的 Cybersecurity Risk 就可能直接變成 Product Risk。所以如果某個關鍵 Supplier 已經停止維護某個 Component，而公司還有大量 Product 依賴它，我自己會希望這件事情可以被 Management 看見，而不是等到 Vulnerability 出現時，大家才第一次知道這個 Component 已經 EOS。

十、Technical Documentation 也可以量，但我不太想只算文件數
最容易建立的 KPI 可能是 Technical Documentation Completion Rate，例如 100 個 Product，有 90 個 Folder 已經建立完成，就是 90%。
但我自己可能更想知道的是 Evidence Completeness（證據完整性）。例如抽樣一個 Product，能不能從 Annex I Requirement（Annex I 要求）一路追到 Risk → Security Control → Verification / Test → Evidence。
如果追得到，我會比較放心；如果追不到，即使 Folder 裡面放了 50 個檔案，我可能還是不太敢說它已經很成熟。所以這一項，我反而會考慮搭配 Sampling Review（抽樣檢視），而不是單純統計文件數量。

十一、我自己很想放一個 Unsupported Component KRI
如果要選一個比較不像傳統 Compliance KPI、但我自己很想長期看的指標，可能就是 Unsupported Critical Component Count（失去支援的關鍵元件數量）。
因為 Product 可能還正常運作、Customer 也沒有抱怨，所有 Dashboard 看起來都很 Green，但底下可能已經有 OS 不再提供 Security Update、Third-party Library 已經 Abandoned（停止維護）、Supplier 不再提供 Security Patch，或 Critical Component 已經 EOS。
這些 Risk 不一定今天就爆炸，而是慢慢累積。所以 Unsupported Component Count 對我而言，很像一種 Early Warning Indicator（早期預警指標）。

十二、KPI 最怕的，是最後大家開始「為 KPI 工作」
這件事情其實不只 CRA 會發生。假設 KPI 定義成「Critical Vulnerability 必須 30 天內 100% Close」，最簡單讓 KPI 達標的方法，不一定是把所有漏洞修掉，也可能變成降低 Severity、大量 Risk Acceptance，甚至提早 Close Case。
最後 Dashboard 全綠，但 Product Security 不一定真的變好。
所以我現在看 Security KPI 時，會多問一句：**「這個指標會不會產生錯誤的行為誘因？」**如果會，我覺得就值得重新設計。

十三、所以我比較喜歡 KPI 與 KRI 成對看
例如 KPI 顯示 Critical Vulnerability Remediation within SLA = 95%，我可能會搭配兩個 KRI：Overdue Critical Vulnerability = 3，以及 Risk Accepted Critical Vulnerability = 5。
這時 Management 看到的，就不再只是「95% Green」，而是同時看到 Performance（績效）與 Residual Risk（剩餘風險）。我自己覺得這樣比較接近 Product Security 真正需要管理的樣子。

十四、那 Management Review 到底要看什麼？
如果 CRA 真正從 Project 轉成 Operating Model（日常運作模式），我不太希望 Management 每季收到一份 50 頁的 Technical Report。我反而會希望有一個相對精簡的 CRA Management View（CRA 管理視圖），可能包括 Product Scope / Classification Status、Major Product Cybersecurity Risk、Critical / Overdue Vulnerability、Article 14 Assessment / Reporting Status、Critical Supplier / Component Risk、Technical Documentation Readiness、Conformity Assessment Readiness，以及 Major CRA Exception。
但我覺得最重要的一欄可能是 Management Decision Required。因為 Management Review 的價值，不只是讓主管知道現在有幾個紅燈，真正重要的是：哪些事情需要跨部門做出 Decision？

十五、Support Period 就是一個很好的例子
假設 Product Team 規劃某個 Product 要提供 5 年 Support Period（支援期間），但其中一個 Critical Component Supplier 只承諾 3 年 Security Support。這時 Security Team 可以指出 Risk，Procurement 可以跟 Supplier 討論，R&D 也可以評估 Replacement（替代元件）或其他 Technical Mitigation（技術緩解措施）。
但如果最後發現 Supplier 不願延長 Support、Replacement 需要重新 Design，而 Product 還預計繼續銷售，那接下來可能就不是 Security Team 自己可以決定的事情。Product Strategy 要不要調整？Support Strategy 要不要改？是否需要投入額外開發成本？Product Lifecycle 是否需要重新規劃？這些已經開始進入 Business Decision（商業決策）。
所以我自己理解 KRI 的目的，不是把 Risk 往 Management 丟，而是：讓真正需要跨部門決策的 Risk，在還有時間處理的時候被看見。

十六、如果是我，我可能先從 8～10 個指標開始
我不會一開始就建立 50 個 CRA KPI / KRI，因為指標一多，很容易最後變成大家每個月忙著填數字。如果是導入初期，我可能先從 CRA Product Classification Coverage、Product Risk Assessment Coverage、Valid SBOM Coverage、Critical Vulnerability Overdue Count、Unsupported Critical Component Count、Article 14 Assessment / Reporting Timeliness、Critical Supplier Security Coverage、Technical Documentation Readiness、Major CRA Exception Count，以及 Conformity Assessment Readiness 這 10 個指標開始。
這份清單只是我自己的管理構想，不是 CRA 官方要求，而且我也不會預期這十個 Indicator 永遠不變。

十七、因為不同階段，我想看的東西本來就應該不同
以目前 CRA 導入時程來看，2026 年我可能最關心 Article 14 Readiness、Product Inventory、Classification 與 Governance，因為 Article 14 Reporting Obligations 已經非常接近。進到 2027 年，管理焦點可能逐漸轉向 Product Cybersecurity Risk Assessment、SSDLC、SBOM、Supplier Security 與 Technical Documentation。
越接近 CRA 全面適用，Conformity Assessment、EU Declaration of Conformity（EU DoC，歐盟符合性聲明）、CE Marking 與 Product Release Readiness 的重要性又會提高。等制度真正進入日常運作後，我可能更常看的是 Vulnerability、Security Update、Support Period、Unsupported Component、Substantial Modification 與 Product Lifecycle Risk。
所以我現在會覺得，KPI 不應該設計一張表，然後十年不變；它應該隨著 Deadline、Product Lifecycle 與 Risk 一起改變。

十八、Management Review，我會更想看 Trend，而不只是單點數字
例如 Overdue Vulnerability（逾期漏洞）從 Q1 的 2 件、Q2 的 5 件增加到 Q3 的 11 件，即使公司設定的 Threshold（門檻值）是 15，所以 Q3 還沒有變成 Red，我可能還是會想問：為什麼連續三季增加？
再例如 Unsupported Critical Component 從 3 → 7 → 18，這可能已經不是單一 Supplier 的問題，而是 Product Portfolio（產品組合）逐漸老化，或 Component Lifecycle Management（元件生命週期管理）開始出現結構性的問題。
所以對我而言，**Trend（趨勢）有時比 Green / Red 更重要。**Green / Red 告訴我現在有沒有超過 Threshold，Trend 則可能提早告訴我：我們正在往哪個方向走。

十九、最後，我還是會回到 Product Risk
KPI 可以很多，Dashboard 也可以做得很漂亮，但我自己最後還是會回到幾個很基本的問題：Product 有沒有出現新的 Attack Surface（攻擊面）？Critical Vulnerability 有沒有真正被處理？Critical Component 還有沒有 Security Support？Security Update 能不能有效提供給 Customer？Risk Assessment 還符合現在的 Product 嗎？需要的 Evidence 還找得到嗎？
因為 CRA Governance 最後真正想管理的，不是 Dashboard，而是 Product Cybersecurity Risk。KPI、KRI、Trend、Management Review，都只是幫助組織持續看見這些 Risk 的管理工具。

Day 23 小結｜好的 CRA Dashboard，不是讓 Management 覺得「全部都很好」
做到 Day 23，我自己對 CRA KPI 最大的心得反而是：不要讓 KPI 只負責報喜。
如果 CRA Dashboard 永遠全部 Green，我可能反而會想問：是真的控制得這麼好，還是 Indicator 設計得太容易達成？
我比較希望 KPI 告訴我們 Process 有沒有正常運作，KRI 告訴我們 Risk 是否正在累積，Trend 告訴我們狀況正在改善還是惡化，而 Management Review 則負責讓真正需要跨部門處理的 Risk 被看見，並形成 Decision 與後續 Action。
所以 CRA 做到這個階段，我自己對 Governance 的想法，已經不太像「Compliance Team 每季跟各單位收一次數字」，而比較像是：建立一套可以持續看見 Product Cybersecurity Risk，並讓組織有能力做出決策與採取行動的管理機制。
這也是我目前研究及參與 CRA 導入後，越來越有感的一件事情：Compliance 的終點，不是證明我們曾經符合；而是讓我們有能力知道自己現在還符不符合。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。CRA 本身並沒有要求企業一定建立本文所列的 KPI、KRI、Dashboard 或 Management Review 架構，這些比較像是我自己嘗試把 CRA 從一次性的 Project Management（專案管理），逐漸轉換成 Continuous Governance（持續治理）的一種方式。

Day 24 預告｜公司已經有 ISO 27001，CRA 還需要重新做一套嗎？
做到 Day 23，如果公司本來就在做 ISO/IEC 27001，應該會開始覺得很多東西很熟悉。Risk Assessment（風險評估）、Vulnerability Management（漏洞管理）、Supplier Security（供應商資安）、Incident Management（事件管理），甚至今天談的 KPI、KRI、Management Review，在既有 ISMS（Information Security Management System，資訊安全管理系統）裡，也都不是陌生的概念。
那問題就來了：公司已經有 ISO/IEC 27001，CRA 還需要重新建立一套嗎？
ISO/IEC 27001 Certificate 能不能直接證明 CRA Compliance？ISMS 做的 Information Security Risk Assessment，跟 CRA 的 Product Cybersecurity Risk Assessment，是不是同一件事情？ISO 的 Incident Response 能不能直接拿來處理 Article 14？Supplier Security 又有多少東西可以直接沿用？
我自己研究與實際思考導入方式之後，反而越來越覺得：ISO/IEC 27001 對 CRA 很有幫助，但兩者看的「主角」其實不太一樣。
ISO/IEC 27001 比較從 Organization（組織）與 ISMS 的角度管理 Information Security Risk；CRA 則把很多要求拉到 Product with Digital Elements，以及 Product Lifecycle（產品生命週期）。兩邊有很多地方可以接起來，但我自己不太會直接畫上等號。
Day 24，我們就來聊：如果公司已經有 ISO/IEC 27001，我自己會怎麼把既有 ISMS 跟 CRA 接起來，哪些能力可以沿用、哪些需要延伸，以及為什麼我不太想為了 CRA 再重新蓋一套完全獨立的管理制度。